WEBVTT Kind: captions Language: en-GB 00:00:01.730 --> 00:00:06.750 Bitcoin: A Peer-to-Peer Electronic Cash System by Satoshi Nakamoto 00:00:06.750 --> 00:00:12.910 Abstract. A purely peer-to-peer version of electronic 00:00:12.910 --> 00:00:16.369 cash would allow online payments to be sent directly from one party 00:00:16.369 --> 00:00:23.160 to another without going through a financial institution. Digital signatures 00:00:23.160 --> 00:00:27.520 provide part of the solution, but the main benefits are lost if a trusted third party 00:00:27.520 --> 00:00:32.960 is still required to prevent double-spending. We propose a solution to the double-spending 00:00:32.960 --> 00:00:39.239 problem using a peer-to-peer network. The network timestamps transactions by hashing 00:00:39.239 --> 00:00:44.120 them into an ongoing chain of hash-based proof-of-work, forming a record 00:00:44.120 --> 00:00:51.219 that cannot be changed without redoing the proof-of-work. The longest chain not only 00:00:51.219 --> 00:00:55.019 serves as proof of the sequence of events witnessed, but proof that it came from 00:00:55.019 --> 00:01:00.539 the largest pool of CPU power. As long as a majority of CPU power is controlled 00:01:00.539 --> 00:01:05.290 by nodes that are not cooperating to attack the network, they'll generate the longest 00:01:05.290 --> 00:01:13.090 chain and outpace attackers. The network itself requires minimal structure. 00:01:13.090 --> 00:01:17.180 Messages are broadcast on a best effort basis, and nodes can leave and rejoin the 00:01:17.180 --> 00:01:22.800 network at will, accepting the longest proof-of-work chain as proof of what happened 00:01:22.800 --> 00:01:26.270 while they were gone. 00:01:26.270 --> 00:01:31.740 1. Introduction Commerce on the Internet has come to rely 00:01:31.740 --> 00:01:35.990 almost exclusively on financial institutions serving as 00:01:35.990 --> 00:01:41.220 trusted third parties to process electronic payments. While the system works well enough 00:01:41.220 --> 00:01:43.280 for most transactions, it still suffers from the 00:01:43.280 --> 00:01:48.990 inherent weaknesses of the trust based model. Completely non-reversible transactions are 00:01:48.990 --> 00:01:51.700 not really possible, since financial institutions cannot 00:01:51.700 --> 00:01:59.070 avoid mediating disputes. The cost of mediation increases transaction costs, limiting the 00:01:59.070 --> 00:02:06.130 minimum practical transaction size and cutting off the possibility for small casual transactions, 00:02:06.130 --> 00:02:10.429 and there is a broader cost in the loss of ability to make non-reversible payments for 00:02:10.429 --> 00:02:14.440 non- reversible services. With the possibility 00:02:14.440 --> 00:02:18.640 of reversal, the need for trust spreads. Merchants must 00:02:18.640 --> 00:02:23.010 be wary of their customers, hassling them for more information than they would otherwise 00:02:23.010 --> 00:02:26.549 need. A certain percentage of fraud is accepted 00:02:26.549 --> 00:02:32.769 as unavoidable. These costs and payment uncertainties can be avoided in person by using physical 00:02:32.769 --> 00:02:35.980 currency, but no mechanism exists to make payments 00:02:35.980 --> 00:02:41.849 over a communications channel without a trusted party. 00:02:41.849 --> 00:02:48.349 What is needed is an electronic payment system based on cryptographic proof instead of trust, 00:02:48.349 --> 00:02:52.870 allowing any two willing parties to transact directly with each other without the need 00:02:52.870 --> 00:02:57.680 for a trusted third party. Transactions that are computationally 00:02:57.680 --> 00:03:03.359 impractical to reverse would protect sellers from fraud, and routine escrow mechanisms 00:03:03.359 --> 00:03:05.720 could easily be implemented to protect buyers. In 00:03:05.720 --> 00:03:12.379 this paper, we propose a solution to the double-spending problem using a peer-to-peer distributed 00:03:12.379 --> 00:03:20.480 timestamp server to generate computational proof of the chronological order of transactions. 00:03:20.480 --> 00:03:24.170 The system is secure as long as honest nodes collectively 00:03:24.170 --> 00:03:31.390 control more CPU power than any cooperating group of attacker nodes. 00:03:31.390 --> 00:03:34.939 2.Transactions 00:03:34.939 --> 00:03:41.090 We define an electronic coin as a chain of digital signatures. Each owner transfers the 00:03:41.090 --> 00:03:44.530 coin to the next by digitally signing a hash of the previous 00:03:44.530 --> 00:03:47.579 transaction and the public key of the next owner 00:03:47.579 --> 00:03:53.480 and adding these to the end of the coin. A payee can verify the signatures to verify 00:03:53.480 --> 00:03:56.749 the chain of ownership. 00:03:56.749 --> 00:04:01.230 The problem of course is the payee can't verify that one of the owners did not double-spend 00:04:01.230 --> 00:04:07.480 the coin. A common solution is to introduce a trusted central authority, or mint, that 00:04:07.480 --> 00:04:11.260 checks every transaction for double spending. After each 00:04:11.260 --> 00:04:13.810 transaction, the coin must be returned to the mint to 00:04:13.810 --> 00:04:20.920 issue a new coin, and only coins issued directly from the mint are trusted not to be double-spent. 00:04:20.920 --> 00:04:25.130 The problem with this solution is that the fate of the entire money system depends on 00:04:25.130 --> 00:04:27.850 the company running the mint, with every transaction 00:04:27.850 --> 00:04:33.660 having to go through them, just like a bank. We need a way for the payee to know that the 00:04:33.660 --> 00:04:39.760 previous owners did not sign any earlier transactions. For our purposes, the earliest 00:04:39.760 --> 00:04:42.630 transaction is the one that counts, so we don't care 00:04:42.630 --> 00:04:48.590 about later attempts to double-spend. The only way to confirm the absence of a transaction 00:04:48.590 --> 00:04:52.540 is to be aware of all transactions. In the mint 00:04:52.540 --> 00:04:55.040 based model, the mint was aware of all transactions and 00:04:55.040 --> 00:05:01.171 decided which arrived first. To accomplish this without a trusted party, transactions 00:05:01.171 --> 00:05:04.730 must be publicly announced, and we need a system for 00:05:04.730 --> 00:05:07.040 participants to agree on a single history of the 00:05:07.040 --> 00:05:13.910 order in which they were received. The payee needs proof that at the time of each transaction, 00:05:13.910 --> 00:05:16.790 the majority of nodes agreed it was the first 00:05:16.790 --> 00:05:19.230 received. 00:05:19.230 --> 00:05:23.580 3.Timestamp Server 00:05:23.580 --> 00:05:29.060 The solution we propose begins with a timestamp server. A timestamp server works by taking 00:05:29.060 --> 00:05:32.150 a hash of a block of items to be timestamped 00:05:32.150 --> 00:05:35.000 and widely publishing the hash, such as in a 00:05:35.000 --> 00:05:41.490 newspaper or Usenet post. The timestamp proves that the data must have existed at the 00:05:41.490 --> 00:05:47.180 time, obviously, in order to get into the hash. Each timestamp includes the previous 00:05:47.180 --> 00:05:51.000 timestamp in its hash, forming a chain, with each additional 00:05:51.000 --> 00:05:57.320 timestamp reinforcing the ones before it. 00:05:57.320 --> 00:06:00.770 4.Proof-of-Work 00:06:00.770 --> 00:06:05.750 To implement a distributed timestamp server on a peer-to-peer basis, we will need to use 00:06:05.750 --> 00:06:10.400 a proof- of-work system similar to Adam Back's Hashcash, 00:06:10.400 --> 00:06:16.020 rather than newspaper or Usenet posts. The proof-of-work involves scanning for a 00:06:16.020 --> 00:06:21.871 value that when hashed, such as with SHA-256, the 00:06:21.871 --> 00:06:27.900 hash begins with a number of zero bits. The average work required is exponential in the 00:06:27.900 --> 00:06:31.030 number of zero bits required and can be verified 00:06:31.030 --> 00:06:34.350 by executing a single hash. 00:06:34.350 --> 00:06:39.940 For our timestamp network, we implement the proof-of-work by incrementing a nonce in the 00:06:39.940 --> 00:06:45.911 block until a value is found that gives the block's hash the required zero bits. Once 00:06:45.911 --> 00:06:48.400 the CPU effort has been expended to make it satisfy 00:06:48.400 --> 00:06:55.400 the proof-of-work, the block cannot be changed without redoing the work. As later blocks 00:06:55.400 --> 00:06:57.741 are chained after it, the work to change the block 00:06:57.741 --> 00:07:03.640 would include redoing all the blocks after it. 00:07:03.640 --> 00:07:08.000 The proof-of-work also solves the problem of determining representation in majority 00:07:08.000 --> 00:07:13.520 decision making. If the majority were based on one-IP-address-one-vote, 00:07:13.520 --> 00:07:19.370 it could be subverted by anyone able to allocate many IPs. Proof-of-work is 00:07:19.370 --> 00:07:27.090 essentially one-CPU-one-vote. The majority decision is represented by the longest chain, 00:07:27.090 --> 00:07:29.460 which has the greatest proof-of-work effort invested 00:07:29.460 --> 00:07:35.460 in it. If a majority of CPU power is controlled by honest nodes, the honest chain will grow 00:07:35.460 --> 00:07:40.170 the fastest and outpace any competing chains. 00:07:40.170 --> 00:07:43.110 To modify a past block, an attacker would have to 00:07:43.110 --> 00:07:47.870 redo the proof-of-work of the block and all blocks after it and then catch up with and 00:07:47.870 --> 00:07:52.440 surpass the work of the honest nodes. We will show later 00:07:52.440 --> 00:07:55.360 that the probability of a slower attacker catching up 00:07:55.360 --> 00:08:01.960 diminishes exponentially as subsequent blocks are added. 00:08:01.960 --> 00:08:06.620 To compensate for increasing hardware speed and varying interest in running nodes over 00:08:06.620 --> 00:08:09.120 time, the proof-of-work difficulty is determined 00:08:09.120 --> 00:08:12.210 by a moving average targeting an average number of 00:08:12.210 --> 00:08:19.440 blocks per hour. If they're generated too fast, the difficulty increases. 00:08:19.440 --> 00:08:22.550 5.Network 00:08:22.550 --> 00:08:30.540 The steps to run the network are as follows: 1) New transactions are broadcast to all nodes. 00:08:30.540 --> 00:08:35.490 2) Each node collects new transactions into a block. 00:08:35.490 --> 00:08:41.909 3) Each node works on finding a difficult proof-of-work for its block. 00:08:41.909 --> 00:08:48.510 4) When a node finds a proof-of-work, it broadcasts the block to all nodes. 00:08:48.510 --> 00:08:56.339 5) Nodes accept the block only if all transactions in it are valid and not already spent. 00:08:56.339 --> 00:09:02.529 6) Nodes express their acceptance of the block by working on creating the next block in the 00:09:02.529 --> 00:09:09.700 chain, using the hash of the accepted block as the previous hash. 00:09:09.700 --> 00:09:12.930 Nodes always consider the longest chain to be the correct one and will keep working on 00:09:12.930 --> 00:09:18.920 extending it. If two nodes broadcast different versions of the next block simultaneously, 00:09:18.920 --> 00:09:22.279 some nodes may receive one or the other first. 00:09:22.279 --> 00:09:24.339 In that case, they work on the first one they received, 00:09:24.339 --> 00:09:29.180 but save the other branch in case it becomes longer. The tie will be broken when the next 00:09:29.180 --> 00:09:32.550 proof- of-work is found and one branch becomes longer; 00:09:32.550 --> 00:09:40.209 the nodes that were working on the other branch will then switch to the longer one. 00:09:40.209 --> 00:09:45.370 New transaction broadcasts do not necessarily need to reach all nodes. As long as they reach 00:09:45.370 --> 00:09:50.570 many nodes, they will get into a block before long. Block broadcasts are also tolerant of 00:09:50.570 --> 00:09:53.990 dropped messages. If a node does not receive a block, 00:09:53.990 --> 00:09:56.639 it will request it when it receives the next block and 00:09:56.639 --> 00:10:00.589 realizes it missed one. 00:10:00.589 --> 00:10:04.809 6. Incentive 00:10:04.809 --> 00:10:08.660 By convention, the first transaction in a block is a special transaction that starts 00:10:08.660 --> 00:10:12.560 a new coin owned by the creator of the block. This adds an 00:10:12.560 --> 00:10:15.170 incentive for nodes to support the network, and provides 00:10:15.170 --> 00:10:20.830 a way to initially distribute coins into circulation, since there is no central authority to issue 00:10:20.830 --> 00:10:24.529 them. The steady addition of a constant of amount 00:10:24.529 --> 00:10:30.949 of new coins is analogous to gold miners expending resources to add gold to circulation. In our 00:10:30.949 --> 00:10:37.029 case, it is CPU time and electricity that is expended. 00:10:37.029 --> 00:10:42.050 The incentive can also be funded with transaction fees. If the output value of a transaction 00:10:42.050 --> 00:10:44.490 is less than its input value, the difference 00:10:44.490 --> 00:10:47.639 is a transaction fee that is added to the incentive value of 00:10:47.639 --> 00:10:52.580 the block containing the transaction. Once a predetermined number of coins have entered 00:10:52.580 --> 00:10:58.709 circulation, the incentive can transition entirely to transaction fees and be completely 00:10:58.709 --> 00:11:01.910 inflation free. 00:11:01.910 --> 00:11:06.660 The incentive may help encourage nodes to stay honest. If a greedy attacker is able 00:11:06.660 --> 00:11:09.540 to assemble more CPU power than all the honest 00:11:09.540 --> 00:11:11.999 nodes, he would have to choose between using it 00:11:11.999 --> 00:11:17.810 to defraud people by stealing back his payments, or using it to generate new coins. He ought 00:11:17.810 --> 00:11:20.580 to find it more profitable to play by the rules, 00:11:20.580 --> 00:11:23.000 such rules that favour him with more new coins than 00:11:23.000 --> 00:11:31.100 everyone else combined, than to undermine the system and the validity of his own wealth. 00:11:31.100 --> 00:11:36.129 7.Reclaiming Disk Space 00:11:36.129 --> 00:11:40.000 Once the latest transaction in a coin is buried under enough blocks, the spent transactions 00:11:40.000 --> 00:11:43.580 before it can be discarded to save disk space. To 00:11:43.580 --> 00:11:47.149 facilitate this without breaking the block's hash, 00:11:47.149 --> 00:11:50.540 transactions are hashed in a Merkle Tree, with only the root included in the block's 00:11:50.540 --> 00:11:53.970 hash. Old blocks can then be compacted by stubbing 00:11:53.970 --> 00:11:57.120 off branches of the tree. The interior hashes do 00:11:57.120 --> 00:11:59.310 not need to be stored. 00:11:59.310 --> 00:12:06.149 A block header with no transactions would be about 80 bytes. If we suppose blocks are 00:12:06.149 --> 00:12:16.709 generated every 10 minutes, 80 bytes * 6 * 24 * 365 = 4.2MB per year. With computer systems 00:12:16.709 --> 00:12:22.369 typically selling with 2GB of RAM as of 2008, and Moore's Law predicting current growth 00:12:22.369 --> 00:12:26.040 of 1.2GB per year, storage should not be a problem 00:12:26.040 --> 00:12:30.910 even if the block headers must be kept in memory. 00:12:30.910 --> 00:12:34.619 8. Simplified Payment Verification 00:12:34.619 --> 00:12:40.149 It is possible to verify payments without running a full network node. A user only needs 00:12:40.149 --> 00:12:42.519 to keep a copy of the block headers of the longest 00:12:42.519 --> 00:12:47.369 proof-of-work chain, which he can get by querying network nodes until he's convinced he has 00:12:47.369 --> 00:12:51.870 the longest chain, and obtain the Merkle branch linking the transaction to the block it's 00:12:51.870 --> 00:12:55.959 timestamped in. He can't check the transaction for 00:12:55.959 --> 00:13:00.579 himself, but by linking it to a place in the chain, he can see that a network node has 00:13:00.579 --> 00:13:04.089 accepted it, and blocks added after it further confirm 00:13:04.089 --> 00:13:09.509 the network has accepted it. As such, the verification is reliable as long 00:13:09.509 --> 00:13:12.020 as honest nodes control the network, but is more 00:13:12.020 --> 00:13:17.100 vulnerable if the network is overpowered by an attacker. While network nodes can verify 00:13:17.100 --> 00:13:22.440 transactions for themselves, the simplified method can be fooled by an attacker's fabricated 00:13:22.440 --> 00:13:28.220 transactions for as long as the attacker can continue to overpower the network. One strategy 00:13:28.220 --> 00:13:30.519 to protect against this would be to accept alerts 00:13:30.519 --> 00:13:35.889 from network nodes when they detect an invalid block, prompting the user's software to download 00:13:35.889 --> 00:13:41.910 the full block and alerted transactions to confirm the inconsistency. Businesses that 00:13:41.910 --> 00:13:43.970 receive frequent payments will probably still want to 00:13:43.970 --> 00:13:49.850 run their own nodes for more independent security and quicker verification. 00:13:49.850 --> 00:13:54.629 9. Combining and Splitting Value 00:13:54.629 --> 00:13:58.879 Although it would be possible to handle coins individually, it would be unwieldy to make 00:13:58.879 --> 00:14:02.740 a separate transaction for every cent in a transfer. 00:14:02.740 --> 00:14:07.480 To allow value to be split and combined, transactions contain multiple inputs and outputs. 00:14:07.480 --> 00:14:12.860 Normally there will be either a single input from a larger previous transaction or multiple 00:14:12.860 --> 00:14:15.699 inputs combining smaller amounts, and at most two 00:14:15.699 --> 00:14:23.620 outputs: one for the payment, and one returning the change, if any, back to the sender. 00:14:23.620 --> 00:14:28.329 It should be noted that fan-out, where a transaction depends on several transactions, and those 00:14:28.329 --> 00:14:34.050 transactions depend on many more, is not a problem here. There is never the need to extract 00:14:34.050 --> 00:14:36.790 a complete standalone copy of a transaction's 00:14:36.790 --> 00:14:39.389 history. 00:14:39.389 --> 00:14:43.970 10. Privacy 00:14:43.970 --> 00:14:48.399 The traditional banking model achieves a level of privacy by limiting access to information 00:14:48.399 --> 00:14:52.860 to the parties involved and the trusted third party. 00:14:52.860 --> 00:14:55.490 The necessity to announce all transactions publicly 00:14:55.490 --> 00:15:00.610 precludes this method, but privacy can still be maintained by breaking the flow of information 00:15:00.610 --> 00:15:06.639 in another place: by keeping public keys anonymous. 00:15:06.639 --> 00:15:10.230 The public can see that someone is sending an amount to someone else, but without information 00:15:10.230 --> 00:15:15.819 linking the transaction to anyone. This is similar to the level of information released 00:15:15.819 --> 00:15:18.559 by stock exchanges, where the time and size of 00:15:18.559 --> 00:15:26.410 individual trades, the "tape", is made public, but without telling who the parties were. 00:15:26.410 --> 00:15:30.499 As an additional firewall, a new key pair should be used for each transaction to keep 00:15:30.499 --> 00:15:33.770 them from being linked to a common owner. Some 00:15:33.770 --> 00:15:38.209 linking is still unavoidable with multi-input transactions, which necessarily reveal that 00:15:38.209 --> 00:15:41.450 their inputs were owned by the same owner. The risk 00:15:41.450 --> 00:15:46.029 is that if the owner of a key is revealed, linking could reveal other transactions that 00:15:46.029 --> 00:15:49.889 belonged to the same owner. 00:15:49.889 --> 00:15:54.399 11. Calculations 00:15:54.399 --> 00:15:58.829 We consider the scenario of an attacker trying to generate an alternate chain faster than 00:15:58.829 --> 00:16:02.111 the honest chain. Even if this is accomplished, it does 00:16:02.111 --> 00:16:05.009 not throw the system open to arbitrary changes, such 00:16:05.009 --> 00:16:10.379 as creating value out of thin air or taking money that never belonged to the attacker. 00:16:10.379 --> 00:16:12.860 Nodes are not going to accept an invalid transaction 00:16:12.860 --> 00:16:16.220 as payment, and honest nodes will never accept a block 00:16:16.220 --> 00:16:21.690 containing them. An attacker can only try to change one of his own transactions to take 00:16:21.690 --> 00:16:25.649 back money he recently spent. 00:16:25.649 --> 00:16:30.929 The race between the honest chain and an attacker chain can be characterized as a Binomial 00:16:30.929 --> 00:16:37.439 Random Walk. The success event is the honest chain being extended by one block, increasing 00:16:37.439 --> 00:16:41.800 its lead by +1, and the failure event is the attacker's 00:16:41.800 --> 00:16:44.800 chain being extended by one block, reducing the 00:16:44.800 --> 00:16:47.980 gap by -1. 00:16:47.980 --> 00:16:53.489 The probability of an attacker catching up from a given deficit is analogous to a Gambler's 00:16:53.489 --> 00:17:00.100 Ruin problem. Suppose a gambler with unlimited credit starts at a deficit and plays potentially 00:17:00.100 --> 00:17:02.430 an infinite number of trials to try to reach 00:17:02.430 --> 00:17:06.459 breakeven. We can calculate the probability he ever 00:17:06.459 --> 00:17:15.520 reaches breakeven, or that an attacker ever catches up with the honest chain, as follows: 00:17:15.520 --> 00:17:18.049 And here there's some mathematics which you can look at at bitcoin.org/bitcoin.pdf 00:17:18.049 --> 00:17:20.380 p= probability an honest node finds the next block 00:17:20.380 --> 00:17:24.222 q1= probability the attacker finds the next block 00:17:24.222 --> 00:17:25.222 qz= probability the attacker will ever catch up from z blocks behind 00:17:25.222 --> 00:17:27.169 The probability drops exponentially as the number of blocks the 00:17:27.169 --> 00:17:33.240 attacker has to catch up with increases. With the odds against him, if he doesn't make a 00:17:33.240 --> 00:17:36.000 lucky lunge forward early on, his chances become 00:17:36.000 --> 00:17:42.480 vanishingly small as he falls further behind. We now consider how long the recipient of 00:17:42.480 --> 00:17:47.130 a new transaction needs to wait before being sufficiently certain the sender can't change 00:17:47.130 --> 00:17:50.679 the transaction. We assume the sender is an attacker 00:17:50.679 --> 00:17:54.520 who wants to make the recipient believe he paid him for a while, then switch it to pay 00:17:54.520 --> 00:17:58.990 back to himself after some time has passed. The receiver 00:17:58.990 --> 00:18:04.380 will be alerted when that happens, but the sender hopes it will be too late. 00:18:04.380 --> 00:18:07.919 The receiver generates a new key pair and gives the public key to the sender shortly 00:18:07.919 --> 00:18:11.720 before signing. This prevents the sender from preparing 00:18:11.720 --> 00:18:13.590 a chain of blocks ahead of time by working on 00:18:13.590 --> 00:18:19.059 it continuously until he is lucky enough to get far enough ahead, then executing the transaction 00:18:19.059 --> 00:18:22.970 at that moment. Once the transaction is sent, 00:18:22.970 --> 00:18:25.760 the dishonest sender starts working in secret on a 00:18:25.760 --> 00:18:31.169 parallel chain containing an alternate version of his transaction. 00:18:31.169 --> 00:18:36.120 The recipient waits until the transaction has been added to a block and z blocks have 00:18:36.120 --> 00:18:40.790 been linked after it. He doesn't know the exact amount of progress the attacker has 00:18:40.790 --> 00:18:46.350 made, but assuming the honest blocks took the average expected time per block, the attacker's 00:18:46.350 --> 00:18:53.309 potential progress will be a Poisson distribution with expected value: 00:18:53.309 --> 00:19:00.240 And here you can check the document, and realize with the equations and c code you will find 00:19:00.240 --> 00:19:04.380 that the probability becomes enormously tiny. 00:19:04.380 --> 00:19:08.049 12. Conclusion 00:19:08.049 --> 00:19:13.550 We have proposed a system for electronic transactions without relying on trust. We started with 00:19:13.550 --> 00:19:17.799 the usual framework of coins made from digital signatures, which provides strong control 00:19:17.799 --> 00:19:20.169 of ownership, but is incomplete without a way 00:19:20.169 --> 00:19:23.900 to prevent double-spending. To solve this, we 00:19:23.900 --> 00:19:28.860 proposed a peer-to-peer network using proof-of-work to record a public history of transactions 00:19:28.860 --> 00:19:33.820 that quickly becomes computationally impractical for an attacker to change if honest nodes 00:19:33.820 --> 00:19:41.760 control a majority of CPU power. The network is robust in its unstructured simplicity. 00:19:41.760 --> 00:19:44.309 Nodes work all at once with little coordination. 00:19:44.309 --> 00:19:47.029 They do not need to be identified, since messages are 00:19:47.029 --> 00:19:54.549 not routed to any particular place and only need to be delivered on a best effort basis. 00:19:54.549 --> 00:19:56.930 Nodes can leave and rejoin the network at will, accepting 00:19:56.930 --> 00:20:02.269 the proof-of-work chain as proof of what happened while they were gone. They vote with 00:20:02.269 --> 00:20:04.799 their CPU power, expressing their acceptance of 00:20:04.799 --> 00:20:10.250 valid blocks by working on extending them and rejecting invalid blocks by refusing to 00:20:10.250 --> 00:20:15.270 work on them. Any needed rules and incentives can 00:20:15.270 --> 00:20:21.740 be enforced with this consensus mechanism. 00:20:21.740 --> 00:20:24.750 This is Stefan Molyneux from Freedomain Radio and I hope this has been very helpful, and 00:20:24.750 --> 00:21:01.039 I encourage you to explore this very exciting world, of shared database information.